Nice @aloubyansky 👍
Could we also check in .quarkus/quarkus-prod-config-dump to maximize cache hit rate?

I'm not sure I understand why "after the third build"?

I'm not sure I understand why "after the third build"?

The caching extension requires the dump configuration file to be created (happens when quarkus.config-tracking.enabled is enabled) in order to make the build goal cacheable.

With the current implementation, you need

• a first build to create the dump configuration file
• a second build to upload the cache entry to the cache node

Thus only the third build would get a cache hit.

This is why I asked to check in the dump configuration file to allow caching from the very first build

Following up @maxandersen's suggestion to not check in .quarkus/quarkus-prod-config-dump, the GitHub workflow can be modified to cache the file (the path to .quarkus should be updated)

Could you update the PR accordingly, @aloubyansky ?

      - name: Cache Quarkus metadata
        uses: actions/cache@v3
        with:
          path: '.quarkus'
          key: ${{ runner.os }}-quarkus-metadata

Ok, I added that adjustment, please review @jprinet and @gsmet. Thanks!

Ok, I added that adjustment, please review @jprinet and @gsmet. Thanks!

LGTM 👍

Failing Jobs - Building fa84f2e

Full information is available in the Build summary check run.
You can also consult the Develocity build scans.

Failures

⚙️ JVM Tests - JDK 17 #

- Failing: integration-tests/opentelemetry-scheduler 

📦 integration-tests/opentelemetry-scheduler

✖ io.quarkus.it.opentelemetry.scheduler.OpenTelemetrySchedulerTest.schedulerSpanTest line 31 - More details - Source on GitHub

org.awaitility.core.ConditionTimeoutException: Condition with io.quarkus.it.opentelemetry.scheduler.OpenTelemetrySchedulerTest was not fulfilled within 1 seconds.
	at org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:167)
	at org.awaitility.core.CallableCondition.await(CallableCondition.java:78)

Closing as I incorporated the changes into #37622 .